Communication systems continue to grow and evolve. Convergence between different types of communication systems, e.g., Internet Protocol (IP), connection-based voice communications, and the like, is advancing rapidly. Recently the phrase “Next Generation Network” (NGN) has been used to describe various activities associated with this evolution. As defined by the International Telecommunications Union (ITU), an NGN is a packet-based network able to provide services (including telecommunication services) and able to make use of multiple broadband, QoS-enabled transport technologies and in which service-related functions are independent from underlying transport-related technologies. NGNs will also likely offer unrestricted access by users to different service providers and will support generalized mobility, which in turn will provide for consistent service provision to end users.
So called “Web Services” are another feature which may become commonplace in NGNs. Web Services provide, for example, a mechanism for interoperability between software entities which reside on different infrastructures and which may be operated by different companies. Web Services are typically defined as providing distributed services using, e.g., the standards suite Web Services Description Language (WSDL), Simple Object Access Protocol (SOAP) and Universal Description, Discovery and Integration (UDDI). For the interested reader, a description of WDSL can be found online as “Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language, W3C Working Draft 3, August 2004”. Similarly, a description of SOAP can be found online as “SOAP Version 1.2 Part 0: Primer (Second Edition), W3C Recommendation 27 Apr. 2007”. Additionally, for UDDI, a standards document entitled “UDDI Version 3.0.2 UDDI Spec Technical Committee Draft, Dated 20041019” can be found online.
Web Services can be characterized as software systems which are designed to support interoperable Machine-to-Machine (M2M) interaction over networks and are most commonly used for Remote Procedure Call (RPC) and as a building block in Service Oriented Architecture (SOA) systems. The web service approach uses WSDL to describe SOAP messaging (which in turn is a protocol used for exchanging XML messages over networks), typically using HTTP as a transport protocol. However, more recently it has been suggested to use Session Initiation Protocol (SIP) as a transport protocol for SOAP messages. SIP is a protocol used predominantly in the telecommunications sector for creating, maintaining and terminating sessions.
Due to the increasing popularity of SIP and SOAP, and the corresponding investments in both standards/technologies by market leading companies, interesting opportunities will arise associated with the creation of convergent applications that cross the boundaries of individual protocol domains. For instance, convergence between SIP and SOAP enables applications such as: Web services initiated multimedia sessions where SIP multimedia sessions are initiated based on the received SOAP message, Sensor network integration applications where sensor networks that provide their functionality through SIP can be exposed as Web Services, and Dial to service applications where a SOAP service is activated upon reception of a call to a specific telephone number. There are existing solutions that utilize SIP and Web Services (SOAP) at the same time. However, these solutions do not, among other things, enable a controlled conversion and coordination between SIP and SOAP protocols.
For example, XML Global Session Protocol (XGSP), as described in an article by Geoffrey Fox, Wenjun Wu, Ahmet Uyar, and Hasan Bulut, entitled “A Web Services Framework for Collaboration and Audio/Videoconferencing”, The 2002 International Multiconference in Computer Science and Computer Engineering, Internet Computing (IC '02), June 2002, Las Vegas, coordinates multiple videoconferencing clients and servers, which are using different protocols (e.g., H.323, SIP, AccessGrid). However, not all of these clients and servers are using SOAP. Thus, XGSP does not offer any SIP to SOAP or SOAP to SIP conversion, and does not handle coordination of multiple SIP/SOAP messages. Instead, XGSP uses SOAP to enable communication between the clients and servers using disparate protocols (i.e., X.323 and SIP).
IBM Corporation offers a product which it refers to as its IMS SOAP Gateway server. According to IBM's description of this product, the IMS SOAP Gateway enables SOAP requests to reach SIP applications and functionalities. Upon reception of SOAP message from a client application, the gateway converts it to a SIP message, and sends the SIP message into a SIP network toward a designated application or functionality. The gateway then receives a SIP output message from SIP and converts it to a SOAP message which is sent back to the client. Conversion of SOAP messages to SIP messages is described in correlator files used by the gateway. However, there is apparently no possibility to specify conversion of SIP messages into SOAP messages in this gateway product. Moreover, the number of applications that the IMS SOAP Gateway can serve at once is dictated by the number of correlator files and back-end SIP applications.
Avaya Inc. offers various products, e.g., Avaya SOA, Avaya SIP Application Server, Avaya Communications Process Manager, etc., which enable access to telecommunications' infrastructure and functionalities through web services (SOAP). These solutions apparently include numerous services that communicate with the telecommunications infrastructure using the SIP protocol. The services are also wrapped as Web Services that enables developers to access telecommunications infrastructure using SOAP requests. However, these Avaya products apparently do not include a solution for generalized conversion between SIP and SOAP.
Accordingly, it would be desirable to provide systems and methods for dynamically adaptive, multi-way message conversion, e.g., SIP to SOAP and SOAP to SIP.